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S malltalk lacks mechanisms for defining private class¬ 
es and private methods. Without private cl asses, class 
naming conflicts can occur. Without private methods, 
encapsulation suffers. While global name spaces can help 
resolve class nami ng conflicts, first-class subsystems with 
private classes can resolve both problems. 

Once a Smalltalk developer has learned the essentials 
of object-oriented design and programming, new issues 
regarding object system design and systematic reuse 
begi n to surface. There are two factors that contri bute to 
design and reuse problems in Smalltalk—both related to 
visibility: 1) all classes are visible to (and usable by) all 
other classes—Smalltalk has a single global name space; 
and 2) all the methods of a class are visible to (and usable 
by) its clients, in spite of the fact that some of its methods 
may be i ntended for the pri vate use of the class. 

This article considers these issues and proposes a sin¬ 
gle remedy for both problems, without changing the 
Smalltalk language and with relatively minor changes to 
the development envi ronment. 

The Name Space Problem 

Because classes are globals in Smalltalk, they are visible to 
all other classes (as well as the programmer). This visibil- 
ity is excessive. It can contribute to information overload 
for novice (as well as experienced) Smalltalk program¬ 
mers. It can also cause class-naming conflicts when 
teams of developers integrate class libraries that have 
been developed separately. 

Few Smalltalk environments include facilities and 
tools for integrating and organizing large libraries of 
Smalltalk classes, though some environments and third- 
party products provide tools for organizing Smalltalk 
source code into more manageable units (e.g., packages, 
applications, and the like). While these facilities help to 
reduce the number of classes immediately visible to a 
programmer, they do not eliminate the problem of having 
a single name space. 

Adding prefixes to class names has become the com¬ 
mon practice for dealing with this limitation. This prac¬ 
tice helps prevent conflicts for commonly used names. 


However, while class-name prefixes prevent potential 
name conflicts, they degrade the readability and under- 
standability of the class names. Understanding degrades 
further when the prefixes abbreviate what should be 
meaningful subsystem names. 

Previous Approaches to Name Space Partitioning 

There are on ly a few workable approaches to partition i ng the 
Smalltalk class name space. Modular Smalltalk 1 addressed 
some of the issues related to the name-space problem. 
However, Modular Smalltalk redefined some of the funda¬ 
mental characteristics of the language and its development 
environment. 

While clear benefits can be gained from astatic version 
of the Smalltalk language—that is, better performance at 
runti me—it remains unclear whether someoftheexi sting 
benefits of Smalltalk might be sacrificed (such as dynam¬ 
ic and rapid application development). Perhaps the best 
of both worlds can be integrated into some future 
SmalItalk envi ronments SmalItalk MT looks promising in 
this regard. 

Meanwhile, other commercial Smalltalk implementa¬ 
tions still show the early origins of Smalltalk as an inter¬ 
preted language. Objects and cl asses are defined and con¬ 
structed dynamical ly usi ng messages. These messages are 
compiled and evaluated in the context of an image-based 
object memory. 

Global Behavior Pools vs. First-Class Subsystems 

Another proposal for deal i ng with the name space problem 
was explored. 2 This proposal used global pool dictionaries 
to supplement the name space provided by the System 
Dictionary. The article showed how pool dictionaries 
(which usually contain system constants) could be extend¬ 
ed to hold classes. Then, other classes could subscribe to 
these behavior pools and use the classes defined in such 
pools—by including the pool names in the poolDictionaries: 
portion of their class definitions. 

Whilethis proposal does help partition the class name 
space, the pools themselves are still global, and the class¬ 
es defined in such pools are still public in the sense that 
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Figure 1. A Subsystem aggregates a Private Class. 


they are still global. Such a pool-based facility issimilar to 
C++ namespaces and the hierarchical namespaces 
provided in QKS’ SmalltalkAgents. They provide separate 
domains for class names without considering whether 
those classes might need to be encapsulated in an object 
system design. 

In contrast, first-class subsystems support the defini¬ 
tion of truly private behaviors. Thus, subsystem classes 
support the organization and encapsulation of clusters of 
related classes. This facility is similar to the C++nested 
class. Pri vate cl asses are nested withi n the scope of a su b- 
system class, which serves as the public interface for the 
private classes it contai ns. A subsystem class can provide 
or restrict access to the private classes it contains, based 
on the needs of the subsystem design. 

As in C++, global behavior pools and subsystems can 
complement each other for resolving class name con¬ 
flicts, and for providing behavior encapsulation. However, 
the remainder of this article focuses on the benefits of 
subsystems and support for their implementation in 
Smalltalk. 

The foundations for implementing first-class subsys¬ 
tems in Smalltalk were established in the February 1993 
issue of TheSmalltalk Report, 3 i n which subsystems were 
called "modules." The terms "subsystem" and "private 
class" serve to better describe the intentions underlying 
this technology, and will be used throughout the remain¬ 
der of this article. 

SUBSYSTEMS AND PRIVATE CLASSES 
A Modeling Notation for Private Classes 

Subsytems are useful for partitioning the behavior of 
object systems. Objects are nothing less than small sys¬ 
tems, and systems are nothing more than largeobjects. 

There i s no conceptual difference between the responsibili¬ 
ties of a class, a subsystem of classes, and even an applica¬ 
tion; it is simply a matter of scale and the amount of rich¬ 
ness and detail in your model. 4 

For these reasons, it would be convenient to have an 
object model notation that shows the relationship 
between objects and systems. The notations that have 
been proposed previously have been internal rather than 


external (for example, they depict subsystems by nesting 
entities graphically). Such internal notations do not scale 
well graphically when they are applied to the design of 
large systems, especially when subsystems are nested (for 
example, when a subsystem class contains a privatesub- 
system class). 

First-class subsystemsfullycontain their privateclass- 
es, including their definitions. Thus, pri vate cl asses can be 
said to be parts of their (public) subsystem class (they are 
aggregated at the meta level). For this reason, the rela¬ 
tionship between a private class and its containing sub¬ 
system class will be depicted using a variant of the OMT 
notation for aggregation. 

In Figure 1, Some Subsystem is a first-class subsystem 
within which Some Private Class isdefined.Theobject mod- 
elsused in further discussions will depict such meta-level 
aggregations of private classes using a special diamond 
(asshown in Figure 1). 

Defining Subsystems and Private Classes 

In addition to introducing a new graphical notation for 
depicting the design relationship between subsystems 
and private classes, this article introduces new message 
formats for defining subsystem classes and their private 
classes in Smalltalk. 

"Define a new subsystem." 

SomeSuperclass 
subsystem: #SomeSubsystem 



Figure 2. Financial Management Subsystem. 
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Figure 3. Object Model fora Facade. 

instanceVariableNames: 
classVariableNames: 
poolDictionaries: ! 

Noticethatsu bsystem c I asses su p po rt i n stan ce var i a b I es, 
class variables, and pool dictionaries, just like ordinary 
classes. Subsystems are first-class objects. A subsystem 
class is just tike any other class, except that its classPool 
may contain private classes in addition to the usual class 
variables. These details will be discussed further in the 
Implementation section. 

Hereafter, in order to simplify the class definitions, the 
message portions after the subclass name will be elided. 
However, please remember that the enti re I ist of message 
arguments is intended and supported for all such abbre¬ 
viated class definitions. For example, the following partial 
message shows the abbreviated form of a subsystem def¬ 
inition. 

"Define a new subsystem." 

SomeSuperclass 

subsystem: #SomeSubsystem ... ! 

A private class can begin the lineage of a privateclasshier- 
archywithin asu bsystem. Such a private base cl ass must be 
defined differently from the other private classes derived 
from it. I n particular, such a private base class must identi¬ 
fy not only its superclass, but also the subsystem that con¬ 
tains it.Thefollowing partial message shows the abbreviat¬ 
ed form of such a private base class defi nition. 

"Define a private base class." 

AnotherSuperclass 
subclass: #SomePrivateClass 
in: SomeSubsystem... ! 

Of course, private classes can also be private subsys¬ 
tem classes. 


"Define a private subsystem class." 
AnotherSuperclass 
subsystem: #SomePrivateSubsystem 
in: SomeSubsystem ... ! 

Once a private class hierarchy has been introduced in a 
subsystem, the private base cl ass and all the subsequent¬ 
ly derived private subclasses can belocated relative to the 
base of the private class hierarchy. The following partial 
message shows the abbreviated form for defi ni ng derived 
private classes. 

"Define a private subclass." 

SomeSubsystem @ #SomePrivateClass 
subclass: #SomePrivateSubclass... ! 

"Define a private subsystem." 

SomeSubsystem @ #SomePrivatedass 
subsystem: #SomePrivateSubsystem... ! 

Visibility Rules for Classes and Subsystems 

The vi sibility and scopi ng rules for private cl asses are si m- 
ilar to those found in C++for nested classes. The classes 
defined outside a subsystem are visible to the private 
classes defi ned i nside a subsystem, whi lethe private class¬ 
es defined inside a subsystem are not (immediately) visi¬ 
ble to the classes defined outside a subsystem. Also, the 
cl asses defi ned within agiven scope of visibility are visible 
to each other. Thus, the private classes defined inside a 
subsystem are visible to each other, just as the classes 
defined in the System Dictionary are visibleto each other. 

Classes defined outside a subsystem may be used 
directly by name in the methods of classes inside a sub¬ 
system. Class names are resolved by looking first in the 
local scope, and then progressing outward through the 
enclosingscopesuntil the named classisfound. 

The binary message @ serves a role similar to that of 
the scope resolution operator:: in C++. It can be used to 
locate a private class relative to its enclosing scope(s). 
Compare the fol lowi ng Smal Ital k and C++expressi ons: 

Smalltalk ( SampleManager @ #SamplePrivateClass) 

C++ ( SampleManager:: SamplePrivateClass) 

DESIGNING OBJ ECT-ORIENTED SOFTWARE SYSTEMS 

Subsystems provide a coherent way to design and organize 
Smalltalk classes that collaborate closely. Several examples 
of subsystem designs are included in the book. Designing 
Object-Oriented SoFTWARE, 5 wheretheorganization of asu b- 
system for managing transactions against financial 
accounts is described. Figure 2 shows how this subsystem 
may be modeled using the new notation for meta-level 
aggregation. 

The class definitions for the financial management 
classes includethe following: 

Object 

subsystem: #FinancialManager... ! 
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Fi g u re 4. Cl assFi I er as a Fagad e. 



Figure 5. Baseline Behavior Classes. 


Object 

subclass: #Account in: FinancialManager... ! 

Object 

subclass: transaction in: FinancialManager... ! 

FinancialManager @ transaction 
subclass: #Balancelnquiry ... ! 

FinancialManager @ transaction 
subclass: #FundsDeposit... ! 

FinancialManager @ transaction 
subclass: #FundsWithdrawal... ! 

FinancialManager @ transaction 
subclass: #FundsTransfer... ! 

Subsystems and the Facade Pattern 

First-class subsystems can be used to implement the 
Fag ade pattern. 

TheFapade pattern providesa unified interfaceto a set of 
interfacesin a subs/stem. TheFagadepattern definesa high¬ 
er-1 a/el interface that makes the subsystem easier to use 5 

Depending on the needs of clients, designers can either 
expose or hide the services provided bythe privateclasses 
hidden behind the Fagade. 

Figure 3 shows a Fagade class, which uses instances of 
two private classes and an instance of one public class 
(defined outside the subsystem). Each instance of the 
Fagadeclassownsan instance of one of the private class¬ 
es, while that instance owns an instance of the other pri¬ 
vate class, which in turn owns an instance of the public 
class. 

This model also serves as an example of the visibility 
and scoping rules. The Fagade can see classes A, B, and C. 
Classes Aand B can seeclassC (which ispublic), but class 
C cannot see cl asses A and B (which are private). 

Private Methods and Client Contracts 

Smalltalk systems use classes to encapsulate the structure 
and state of objects. FHowever, while Smalltalk classes 
encapsulate the state of thei r i nstances, they do not encap¬ 
sulate their behavior. All the methods of a class are effec¬ 
tively public. 

Traditionally, a Smalltalk developer indicates that a 
method is intended for the private use of the implement¬ 
ing class, using the notation Private at the beginning of the 
method comment. This convention requires the client 
developer to inspect the source code of the method, in 
order to discover whether a method is intended for public 
usage. 

In systems that support method organization (i.e., pro¬ 
tocols), the method developer can organize the method in 
a protocol whose name indicates that the methods are 
private. Flowever, Smalltalk does not enforce the privacy 
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indicated by either of these conventions So, client devel¬ 
opers sometimes use the private methods anyway, and 
thereby create dependencies that the class designer did 
not intend to permit or support. 

In Smalltalk, it is not always clear what such privacy 
means anyway. For example, should subclasses be 
restricted from using private methods they inherit from 
their superclasses? While C++ provides explicit access 
control mechanisms for public, protected, and private 
members, Smalltalk does not provide any mechanisms 
for access control. 

It can be argued that 
the traditional notions of 
access in object-oriented sys¬ 
tems are simplified ways of 
specifying the class of the 
clients that are permitted to 
use the methods of a server 
class. Table 1 suggests how 
access rel ates to c I i ents. 

This table formalizes 
a notion that has appeared repeatedly in the literature on 
object-oriented design: promised behavior. The classes 
that collaborate closely within a subsystem often exhibit 
promised behavior, especially when the classes in the sub¬ 
system form contractual agreements regarding their ser¬ 
vices. Thus, it would be advantageous to object system 
designers if object-oriented languages incorporated and 
enforced access mechanisms, based on client specifica¬ 
tions to establish such formal contracts. Object-oriented 
languages would improve their ability to model such con¬ 
tracts if they were extended beyond the traditional support 
for only private, protected, and public access (which are 
supported by languages likeC-H-and Java). Indeed, private, 
protected, and public access mechanisms can be con¬ 
ceived of as specific kinds of promised contracts as shown 
in Table 2 (with respect to a given server class). 

Note that in Table 2 public methods are promised to nil 
because the class Object and all other root classes are 


derived from nil—all the root classes have no superclass. 
Thus, public methods are available to any other defined 
method, whether the method isdefined in aclassderived 
from Object, or any other root class. 

Private Classes for Private Methods 

The following discussion describes how you can use pri¬ 
vate cl asses to implement private methods— even without 
direct language support for private methods. First, build 
the pu bl i c i nterface usi ng an i nstance of a su bsystem cl ass. 

The subsystem i nstance con- 
tains a single instance vari¬ 
able, and the instance vari¬ 
able contains an instance of a 
private class. The private 
class contains those methods 
you want hidden. When the 
public class (the subsystem) 
is instantiated, it creates and 
holds an instance of the pri¬ 
vate class. Each of the public 
methods (in the public class) uses the private methods 
supplied by the instance of the private class. Figure 4 
shows this arrangement using an object model. 

TheclassdefinitionsforthisFagadeincludethefollowing: 

Object 

subsystem: #ClassFiler 
instanceVariables: 'privateFiler' 
classVariables:" 
poolDictionaries:"! 

Object 

subclass: #PrivateFiler 
in: ClassFiler 

instanceVariables: 'behavior' 
classVariables:" 
poolDictionaries:''! 

Implementation 

This section outlines how the facility for defining 
subsystems and private classes can be added to 
Visual Smalltalk. We will focus on those aspects of 
the Behavior classes that change when subsystems 
are added. First, note how the baseline Behavior 
classes are organized in Figure 5. Behavior inherits 
from Object. Class and MetaClass inherit from 
Behavior. Object class inherits from Class. The other 
metacl asses of the su bcl asses of Obj ect i n heri t from 
Object class. 

General ly speaking, the class and metaclass i nher- 
itance hierarchies parallel each other. Thus, for 
example: 

Point superclass == Object 
Point class superclass == Object class. 

However, there is an anomaly at class Object, where 


Access 

Implied Client Specification 

private.... 

only the implementing class 

protected. . . . 

theimplementingclassand all derived classes 

promised. . . . 

some specific collaborating class (which need 


not be related by inheritance) 

public. . . . 

any class (without regard for inheritance) 


Table 1 represents how access relates to clients. 

Access 

Equivalent Contract 

ServerClass private 

ServerClass promisedTo: ServerClass only 

ServerClass protected 

ServerClass promisedTo: ServerClass any 

ServerClass public 

ServerClass promisedTo: nil 


Table 2 represents private, protected, and public mechanisms. 


Software devel opersneed I anguage 
fad I i ti esthat provi de desi gn opti ons. 
This i son e of the reasons that C ++ 
has evol ved so much over 
the past several years. 
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Figure 6. Class vs."Subsystem’’ Class. 



Figure 7. Behavior Extensions for Private Classes. 

Object superclass = nil 
Object class superclass = Class. 

Subsystems and private cl asses requi re some minor alter¬ 
ations to these baseline relationships. As noted previous¬ 
ly, each subsystem is a class. While an ordinary class uses 


a Dictionary for its classPool, a subsystem class uses a 
Subsystem Dictionary. Each Subsystem Dictionary pro¬ 
vides a unique domain for the private classes and class 
variables of the subsystem. Private class names are 
mapped to Private Classes, while class variable names are 
mapped to class variables. Figure 6 provides a model of 
these relationships. 

Each Private Class knows its class (a Private MetaClass). 
Each Private MetaClass knows its subsystem (a subsystem 
class). Thus, indirectly, each Private Class knows the 
enveloping subsystem class. Given the foregoing relation¬ 
ships, Figure 7 shows the relationships for the new 
Behaviors. 

In particular, note how 

Object class superclass == PrivateClass. 

This relationship replaces the normal baseline relation¬ 
ship, where 

Object class superclass == Class. 

Because each private metaclass knows the subsystem 
to which it belongs, the compiler can identify the scopes 
that enclose the private behaviors (class and metaclass). 
This simplifies changes to the compiler interface to 
extend the visibility rules and resolve class names into 
classes. 

CONCLUSION 

Benefits of Subsystems and Private Classes 

Software developers need language facilities that provide 
design options. This is one of the reasons that C++ has 
evolved so much over the past several years. Some of the 
recent additions (nested classes, templates, namespaces, 
and runtime type information) show progress toward fea¬ 
tures found in pure object-oriented systems like 
Smalltalk, and even some advances over features in 
Smalltalk. 

Two of these C++features directly address the class 
naming problem in complementary ways: namespaces 
and nested classes (i.e., private classes). This article has 
considered how support for private classes can be added 
to Smalltalk in conjunction with first-class subsystems. 
Subsystem classes provide an additional design dimen¬ 
sion beyond that provided by ordinary classes. 
Subsystems and their private classes permityou to: 

• resolveclass name conflicts with separate name 
spaces; 

• integrate separately developed class libraries; 
•organizecollaborations between classes into first- 

class subsystems; 

• implement the Fagade pattern; and 

•define private methods only visible to those in a 
public i nterface (su bsystem) cl ass. a 
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